It is often desirable for administrators of anti-malware products to specify exclusions to anti-malware scanning. While an anti-malware product can keep computers safe by scanning files to identify malware, certain applications may be trusted, and it may be preferable to exclude some of these from scanning. Exclusions can be desirable for various reasons, such as performance and compatibility.
On the performance side, real-time anti-malware scanning can slow down an application considerably. The actual performance impact depends upon the characteristics of the application. An extreme case would be an application that repeatedly opens a file, writes to it, and then closes the file. Unless the application is excluded, the target file will be scanned for malware each time the application opens it, writes to it and closes it. This will slow down the application considerably. Even in less extreme cases, an application's performance can be significantly affected by anti-malware scanning.
In cases in which a negative performance impact is noticeable but the application in question is trusted not to create or spread malware, the application can be safely excluded from anti-malware scanning. Doing so will restore that application's performance to an acceptable level. For example, if the application that repeatedly opens, writes to, and closes a file is trusted not to infect files with malware, the application can be excluded. In this case, the target file is not scanned when it is accessed by the application, and the performance of the application is greatly improved.
On the compatibility side, some applications create and process structured data files. Malware can exist within the context of these structured files. However, anti-malware programs will corrupt the structured data store if a repair is attempted. An example of this is Exchange server. Emails are stored within the structured Exchange file set, and these e-mails might contain malware in attachments. However, a direct file based repair on an Exchange data file without coordination with Exchange will corrupt the metadata associated with that email, thereby corrupting the Exchange data store. Structured database applications such as SQL Server and Oracle are subject to this same anti-malware corruption problem.
Some conventional anti-malware products integrate auto-exclusions based on auto-detection of a specific version of a given structured data based application. The problem with this approach is that it only gives an anti-malware vendor limited coverage for specifically supported products, but not for the full range of applications. Typically, the applications supported for auto-exclusions make up a small subset of all the applications that use structured data.
In conventional anti-malware products, exclusions are specified by folder and/or filename. This is true both for trusted applications for which an administrator wishes to avoid performance degradation, as well as for structured data based applications for which auto-exclusion is not supported. Specifying exclusions in this manner is burdensome, and potentially ineffective. In some cases, many different files and folders may be utilized by a given application, not all of which may be known to the administrator. Even where the folder and filenames associated with a trusted application are known, these can change with subsequent versions of the application. The updated information may not be known to the administrator, in which case the old specified exclusions will no longer be adequate. In addition, the application's folders may vary between installations. In any case, specifying exclusions for multiple and potentially changing folder and filenames is labor intensive and inconvenient, even where the names are known. Furthermore, the relationships between applications and file systems can be complicated to the extent that excluding an individual application is not necessarily practicable.
Consider the scenario of a Configuration Management (CM) system used for building products. The multiple processes of the CM system related to building a product create executable files. Once created, these executable files are typically copied to some specific location, such as a file server (e.g., a Server Message Block (SMB) file share). As it is good policy to run an anti-malware product on file servers, the executable files copied from the CM system to the file server will be scanned for malware upon upload. This will significantly slow down the upload process, as the anti-malware product on the file server scans each uploaded file. However, the CM, through its processes, is trusted to create malware-free executable files. So, it would be desirable to skip the scanning of the uploaded executable files on the file server. With conventional folder and file name based exclusions, it would be very labor intensive and burdensome to exclude the uploaded executable files from scanning on the file server based on trusting the CM system.
It would be desirable to address such issues.